Companies regularly perform work and accomplish tasks through business processes. A business process provides a mechanism through which one or more tasks and phases of an overall activity are related. Accomplishing each of the tasks accomplishes the overall activity. For example, an organization may have a hiring process, with phases for gathering candidates, evaluating the candidates, and finally bringing on selected candidates. Each of the phases may have one or more tasks. For example, for the gathering candidates phase, tasks may include marketing a job opening, gathering résumés, screening the résumés, scheduling interviews with selected candidates, or other or different tasks. Note that each of the above phases may have different labels, and there may be fewer or more phases. Although a simple hiring process is provided, business processes can be related to any area of an organization, including sales, finance, marketing, manufacturing, shipping, etc.
The business processes of an organization can provide a great value in terms of efficiency and the ability to accomplish work that affects an organization's bottom line. An organization's business processes should evolve over time to keep pace with progress, such as introducing new innovations, new technology, separating out tasks as the organization or its departments expand, etc. Traditional modification or evolution of business processes involved wholesale changes, where “current” business processes were replaced with “updated” business processes meant to replace them. The traditional changing of business processes had inherent uncertainty and risk. A glitch in the updated procedure could result in costly delays and actually introduce inefficiencies into the process. Replacing one process with another represented a significant investment that delayed implementation of changes due to the nature of changing business processes.
Even if an organization had business processes in place, as an organization grew it was possible that different, and not necessarily completely compatible, business processes could be developed in different areas or departments of the organization. The business process may not necessarily be run using the same software. The use of fragmented business processes results in inefficiencies due to redevelopment of similar processes and the maintenance of processes that are different, but attempt to achieve similar goals. The deployment of various backend systems (e.g., customer relations management (CRM), enterprise resource planning (ERP), etc.) traditionally did not allow reuse of processes from one system to another. Thus, to use business process, or generate a new business process, access was generally limited to a single source of business processes or a single backend system, even if other sources or systems had business processes that may be desirable for a particular implementation.
Additionally, current systems may allow development of procedures through the use of ad hoc workflows, which generally allow development of a procedure in a piece-by-piece manner. The piece-by-piece development is in contrast to generating workflows or a sequence of work activities/actions from a business process by creating the actions for actual implementation by specific individuals or roles (e.g., manager, financial approver, etc.). Ad hoc workflows develop as an overall activity is executed piece by piece. Each point in the sequence of the workflow becomes a workflow object, and a new object is generated for each phase of the overall workflow. Ad hoc workflows have traditionally been limited to the local context in which they were developed; specifically, ad hoc workflows do not traditionally connect into the common system that is available to the separate backend systems. Thus, an ad hoc workflow may be developed that is unavailable for access except within the backend system in which it was created.